AT Protocol
進行中の作業
このドキュメントは完全ではありません。 更新のため、近日中に再度ご確認ください。
Authenticated Transfer Protocol 承認済み転送プロトコル
用語集
クライアント: ユーザーのデバイスで実行されているアプリケーション。 PDS を介してネットワークと対話します。
Personal Data Server (PDS): ユーザー データをホストするサーバー。 ネットワーク上でユーザーのパーソナル エージェントとして機能します。
Name Server: ドメイン(handle)からDIDにマッピングするサーバー。 com.atproto.identity.resolveHandle() APIを使います。多くの場合はPDSです。 クローリングインデクサー: 集約されたビューを生成するためにサーバーをクロールしているサービス。
Wire protocol (XRPC)
ATP は、XRPC と呼ばれる HTTPS 上の軽量ラッパーを使用します。 XRPC は、グローバル スキーマ システムである Lexicon スキーマ を使用して、ホスト間の動作を統一します。 atproto.com Lexicon には、ATP で使用されるすべての XRPC メソッドが列挙されています。 Identifiers 識別子
次の識別子が ATP で使用されます。
table:Identifiers
識別子 用途
Domain names リポジトリを弱く識別する一意のグローバル識別子。
DID リポジトリを強力に識別する一意のグローバル識別子。
NSID レコードタイプとXRPCメソッドを識別する一意のグローバル識別子。
TID レコードを識別するタイムスタンプベースのID。
Domain names
ドメイン名 (別名 "handles" 「ハンドル」) は、リポジトリを弱く識別します。 これらはUIで使われる便利なものですが、いつでも変更される可能性があるため、データを参照するためにレコード内で使用されることはめったにありません。 repo DID は、安定した識別子を提供するために推奨されます。
DIDs
DID は、リポジトリを強力に識別する一意のグローバル識別子です。 これらは、ユーザーのライフサイクル中に変更されるべきではないため、「強力」と見なされます。 UI で使用することはめったにありませんが、データを参照するために常にレコードで使用する必要があります。
ATP は、次の 2 つの DID メソッドをサポートしています:
Web (did:web)。 ユーザーが「セルフホスティング」であり、ドメイン名とサーバーを直接制御している場合にのみ使用する必要があります。 テスト中に使用することもできます。
Placeholder (did:plc)。 ホストに依存しないグローバルなセキュア ID を提供するために ATP とともに開発された方法。
DID は、レポのホストのアドレスと、レポの更新に署名するために使用される公開鍵を提供する「DID Documents」がどこにあるのかを解決します。
Timestamp IDs (TID)
TODO
TID の説明
URI scheme
table:example
Repository at://alice.host.com
Repository at://did:plc:bv6ggog3tya2z3vxsub7hnal
Collection at://alice.host.com/io.example.song
Record at://alice.host.com/io.example.song/3yI5-c1z-cc2p-1a
Record Field at://alice.host.com/io.example.song/3yI5-c1z-cc2p-1a#/title
スキーマ
ATP は、XRPC メソッドとレコード タイプに厳密なスキーマ定義を使用します。 これらのスキーマは、NSID を使用して識別され、Lexicon(Lexicon スキーマ)を使用して定義されます。 リポジトリ Repositories
「リポジトリ」"repository" は、署名されたレコードのコレクションです。
これは、Merkle Search Tree (MST) の実装です。 MST は、順序付けされた、挿入順序に依存しない、決定論的なツリーです。 キーはアルファベット順に配置されています。 MST の重要な洞察は、各キーがハッシュされ、最初の 0 がカウントされて、どのレイヤーに該当するかが決定されることです (~32 のファンアウトに対して 5 つのゼロ)。 これはマークル ツリーであるため、各サブツリーはそのハッシュ (CID) によって参照されます。 リーフが変更されると、そのリーフへのパス上のすべてのツリーも変更されるため、ルート ハッシュが更新されます。
Repo データレイアウト
TODO
データ レイアウトと MST の編成方法について、より詳細な説明を提供します。
リポジトリ データ レイアウトは、ネットワーク転送可能なデータの単位を確立します。 これには、次の 3 つの主要なグループが含まれます。
Grouping 説明
Repository
リポジトリは、ATP ネットワーク内の単一の「ユーザー」のデータセットです。 すべてのユーザーには、DID で識別される単一のリポジトリがあります。 Collection
コレクションは、レコードの順序付きリストです。 すべてのコレクションは NSID によって識別されます。 コレクションには、NSID によって識別されるタイプのレコードのみが含まれます。 Record
レコードはキー/値ドキュメントです。 これは、ネットワーク上で送信できるデータの最小単位です。 すべてのレコードにはタイプがあり、TID によって識別されます。
ノード型 と説明
Signed Root ("commit") 署名付きルート、または "commit" は、リポジトリの最上位ノードです。次を含む：
root ルートノードの CID
sig 署名。
Root Rootノードは次を含む
did このレポジトリのDID
prev このレポジトリの履歴内の前のコミットノードのCID
data マークル検索ツリーの最上位ノード
auth_token jwt でエンコードされた UCAN このルートを生成した書き込みを行う権限を与える。
MSTノード マークル検索ツリー ノード
l (オプション) 左端のサブツリーの CID。
e MST エントリの配列。
MST エントリー マークル検索ツリーのエントリには次が含まれます。
p このキーが prev キーと共有する utf-8 文字のプレフィックス数。
k 共有プレフィックスの外側の残りのキー。
v エントリーの値の CID。
t (オプション) 次のサブツリー (リーフの右側) の CID。
Repo エンコーディング
リポジトリ内のすべてのデータは、CBOR を使用してエンコードされます。 次の値の型がサポートされています。 boolean 21 (true) または 20 (false) のsimple valueを持つ CBOR simple value (メジャー タイプ 7、サブタイプ 24)。 float CBOR 浮動小数点数 (メジャー タイプ 7)。 すべての浮動小数点値は、整数値であっても 64 ビット (追加の型値 27) としてエンコードする必要があります。 list CBOR 配列 (メジャー タイプ 4)。リストの各要素が、そのタイプに従って配列の値として順番に追加されます。 map 各エントリが CBOR mapのメンバーとして表される CBOR map (メジャー タイプ 5)。 エントリキーは、キーとして CBOR string (メジャー タイプ 3) で表されます。 TODO
値の型がありませんか? バイナリ？ CID/リンク?
Repo CBOR の正規化
TODO
正規化アルゴリズムを説明する
Repo レコード
Repo レコードは、CBOR でエンコードされたオブジェクトです (JSON 互換の CBOR タイプのみを使用します)。 各レコードには、lexicon (lexicon スキーマ)によって定義される「型」"type"があります。 型は、レコードと予想されるレコードのスキーマを含むコレクションを定義します。 ATP はドル ($) プレフィックス付きフィールドをシステム フィールドとして使用します。 次のフィールドには、システムの意味が与えられます。
table:field
フィールド 用途
$type レコードのタイプを宣言します。 （必要）
$ext レコードの基本スキーマへの拡張が含まれています。
$required サポートが必要かどうかを示すために拡張機能によって使用されます。
$fallback 不足しているデータの説明を提供するために拡張機能によって使用されます。
Client-to-server API
Client-to-server APIは、クライアントアプリケーションとユーザーのPDSとの間の通信を駆動する。APIは、PDSが実装するlexiconsによって決定されます。すべてのPDSが atproto.com lexicon をフルサポートすることが推奨されています。bsky.app などのアプリケーションレベルのlexiconも推奨されます。
Authentication 認証
TODO
クライアントが PDS でどのように認証するかを記述します。 (単純な JWT ベースのセッションです。)
ATP core lexicon
com.atproto.* lexiconsは、以下の動作を提供します:
com.atproto.label
追加のlexicons
ATPが実用的に役立つためには、さまざまな高度なクエリや動作をサポートする必要があります。これらの高度な動作は、ユーザー端末で実装することも可能ですが、その場合、サーバーに比べて動作が遅くなります。そこで、PDSには、より高度なAPIを提供する lexicon を実装することが期待されます。Blueskyが作成したリファレンスPDSは、bsky.app lexiconを実装しています。
Server-to-server API
サーバー間APIは、フェデレーション(連合)、イベント配信、グローバルインデックスを実現します。また、メール配信やフォーム送信など、アプリケーションの動作を提供するために使用されることもあります。
Authentication 認証
TODO
サーバーが互いに認証する方法について説明する。